پوهنتون کابل پوهنحی كمپيوترساینس پوهنیار محمد شعیب "زرین خیل"

Transcription

1 پوهنتون کابل پوهنحی كمپيوترساینس : : تهیه کننده سال پوهنیار محمد شعیب "زرین خیل" 1389

2 Introduction to Database and Data Models - Relational Model 08 By: M Shuaib Zarinkhail 2010

3 Referential Integrity Constraint (RIC) Def. A foreign key s values must appear in the parent relation s primary key! Example: EMP(EMP#, Name, DOB, ) COMPANYCAR(VIN, EMP#, Color, ) The value found in EMP# in COMPANYCAR, must also appear in EMP# in EMP Spring 2010 By: CSF / KU 199

4 RIC Referential Integrity the requirement that the value placed in a Foreign Key must already exist in the table you are linking to (parent table) Most DBMSs enforce this automatically Spring 2010 By: CSF / KU 200

5 RIC Example Spring 2010 By: CSF / KU 201

6 RIC Example Spring 2010 By: CSF / KU 202

7 RIC Example STUDENT(NID, Name, Major, Building, Room) DORMROOM(Building, Room, Phone) In this case: the values for Building and Room must be presented in DORMROOM Prior to being used in STUDENT Spring 2010 By: CSF / KU 203

8 Special Cases Case 1: Strong entities Case 2: Weak entities Case 3: Super/Sub Class structures Spring 2010 By: CSF / KU 204

9 Case 1: Strong Entities Most common case Create a relation for each entity that contain the entity s attributes Identify the Primary key (PK) Add any necessary foreign keys to indicate relationships between entities Spring 2010 By: CSF / KU 205

10 Strong Entity Example EMPLOYEE(EmpNo, Name, Address) DEPT(DeptNo, DeptName, Location) Spring 2010 By: CSF / KU 206

11 Case 2: Weak Entities An entity where an instance must be associated with another (strong) entityinstance in order to exist Existence of weak entity instance depend on a strong entity instance Example: EMPLOYEES and DEPENDENTS Dependents can not exist without a corresponding employee Spring 2010 By: CSF / KU 207

12 Weak Entity Example EMPLOYEE (EmpNo, Name, ) DEPENDENT (EmpNo, Name, ) Spring 2010 By: CSF / KU 208

13 Case 3: Super/Sub Class Structures Each entity becomes a relation All entities have the same primary key The primary key is shown in the parent relation (ERD) Child entities inherit attributes & relationships from parent entities Can be Top-Bottom or Bottom-Up Spring 2010 By: CSF / KU 209

14 Super/Sub Class Structures Spring 2010 By: CSF / KU 210

15 Super/Sub Class Structures VEHICLE(VIN, #Passengers, Manufacturer, Model, Year) MOTORCYCLE(VIN, #Wheels, EngineSize) TRUCK(VIN, MaxWeight, FuelUsed) TRAILER(VIN, MaxWeight, #Wheels) Spring 2010 By: CSF / KU 211

16 Functional Dependency Foreign keys are used to show the relationships between entities Functional dependencies are used to show the relationships between attributes within a relation Spring 2010 By: CSF / KU 212

17 Functional Dependency Def: if an attribute (A) determines the value of another attribute (B), then A functionally determines the value of B Notation: A B Determinant Spring 2010 By: CSF / KU 213

18 Example Spring 2010 By: CSF / KU 214

19 Rules for Functional Dependencies A set of attributes can form a functional dependency: A,B,C D Dependencies like A B, A C, and A D can be abbreviated as A B C D Spring 2010 By: CSF / KU 215

20 Rules for Functional Dependencies Transitivity Given A B and B C in a relation, then A C This rule allows you to derive new functional dependencies from the existing ones Spring 2010 By: CSF / KU 216

21 Functional Dependency Example What functional dependencies exist in this relation? Spring 2010 By: CSF / KU 217

22 Determining Keys In many cases, the primary key and candidate keys are going to be determinants Look for the functional dependencies Look for determinants or sets of determinants that cover all of the nondeterminant attributes in a relation Spring 2010 By: CSF / KU 218

23 Introduction to Database and Data Models - Normalization 10 By: M Shuaib Zarinkhail 2010

24 In This Chapter What normalization is and what role it plays in database design Normal forms: 1NF, 2NF, 3NF, BCNF, (4NF, 5NF, DKNF) How normal forms transformed from lower normal forms to higher normal forms? Spring 2010 By: CSF / KU 244

25 In This Chapter cont That normalization and E-R modeling are used concurrently to produce a good database design That some situations require denormalization to generate information efficiently Spring 2010 By: CSF / KU 245

26 Review Relations: Two dimensional data (tables) Cells must be single value Column names must be unique Columns must have the same data type Order of rows and columns is not relevant Spring 2010 By: CSF / KU 246

27 Normalization Def. Decomposing relations to avoid anomalies when inserting, updating or deleting data Normalization Steps: Every determinant in a relation must be a candidate key If not, split relation into two or more new relations Also serves to reduce redundancy of data Spring 2010 By: CSF / KU 247

28 Normalization and Database Design Normalization should be part of the design process E-R Diagram provides macro view Normalization provides micro view of entities Focuses on characteristics of specific entities May yield additional entities Spring 2010 By: CSF / KU 248

29 Anomalies Redundancy: information repeated in multiple locations Update: failure to change all instances of a specific value Delete: delete data and lose other values as a side effect problem Spring 2010 By: CSF / KU 249

30 Anomalies cont Insert: need to add data about multiple themes adding rows may force users to add information about another General Rule of Thumb: a table should not pertain to more than one entity type Spring 2010 By: CSF / KU 250

31 Example EMPLOYEE 2 Emp_ID Name DepN Salary Course Date 100 Margaret Marketing SPSS 6/19/200X 100 Margaret Marketing Surveys 10/7/200X 140 Alan Account Tax Acc 12/8/200X 110 Chris Info Sys SPSS 1/12/200X 110 Chris Info Sys C++ 4/22/200X 190 Lone Finance C Susan Marketing SPSS 6/19/200X 150 Susan Marketing Java 8/12/200X Spring 2010 By: CSF / KU 251

32 Example Cont Question - Is this a relation? Answer - Yes: unique rows Question - What s the primary key? Answer - Composite: Emp_ID, Course_Title Spring 2010 By: CSF / KU 252

33 Anomalies in this Table Insertion - can t enter a new employee without having the employee take a class Deletion - if we remove employee 140, we loose information about the existence of the Tax Acc course Modification - giving a salary increase to employee 100 forces us to update multiple records Spring 2010 By: CSF / KU 253

34 Anomalies in this Table Cont Why do these anomalies exist? Because we ve combined two themes (entity types) into one relation This results in duplication, and an unnecessary dependency between the entities Spring 2010 By: CSF / KU 254

35 Normalization Addresses these anomalies by removing data redundancy We will cover the following types of normalization: First Normal Form 1NF Second Normal Form 2NF Third Normal Form 3NF Boyce-Codd Normal Form (BCNF) Spring 2010 By: CSF / KU 255

36 Normalization Cont There are several other forms of normalization which will not cover in this course: Fourth Normal Form 4NF Fifth Normal Form 5NF Domain Key Normal Form (DKNF) Spring 2010 By: CSF / KU 256

37 First Normal Form 1NF The table must meet the definition of a relation: No repeating groups Each cell hold a single value An attribute s entries are all of the same kind No two identical rows Unique names for each column Irrelevant order of rows and columns Spring 2010 By: CSF / KU 257

38 First Normal Form Cont If a table meets the criteria of being a relation, it is directly in 1NF 1NF: The simplest normal form Does little to reduce anomalies Is a required precursor to other normal forms Spring 2010 By: CSF / KU 258

39 Second Normal Form 2NF A relation is in 2NF if it is in 1NF and all of its non-key attributes are dependent on all parts of the PK or PK consists of only one attribute No partial-dependency Non-key attributes: all attributes that are not PK or part of the PK Dependent: Attributes appear on the right side of a functional dependency Spring 2010 By: CSF / KU 259

40 Second Normal Form Cont This form really affects composite keys Composite Keys: Keys that are made up of multiple attributes Example: DORMROOM(Building, Room, Phone) Spring 2010 By: CSF / KU 260

41 Third Normal Form 3NF A relation is in 3NF if it is already in 2NF and contains no transitive dependencies Transitive Dependency: an attribute is functionally dependent on another nonkey attribute Spring 2010 By: CSF / KU 261

42 Boyce-Codd Normal Form (BCNF) In BCNF, every determinant in a relation should be a candidate key Determinant is an attribute whose value determines other values in a record 3NF table with one candidate key is already in BCNF Spring 2010 By: CSF / KU 262

43 Denormalization Sometimes, normalizing a table make more work or cause problems In such cases, the following problems may occur: Additional processes need to access data Ambiguous data appear Unknown data appear Data entry become difficult etc Spring 2010 By: CSF / KU 263

44 Denormalization In such case, we can keep a table de-normalized Normalization is one of many database design goals Normalized table requirements Additional processing Loss of system speed Spring 2010 By: CSF / KU 264

45 Denormalization Normalization purity is difficult to sustain due to conflict in: Design efficiency Information requirements Processing Spring 2010 By: CSF / KU 265

46 Denormalization Therefore, we can keep a table in its denormalized form This is shown in the following example: STUDENT(ID, Name, Street, District, Province) The STUDENT table is kept denormalized Spring 2010 By: CSF / KU 266

47 De-normalized Table Defects Data updates less efficient Indexing more cumbersome No simple strategies for creating views Spring 2010 By: CSF / KU 267

48 Introduction to Database and Data Models - Normalization 11 By: M Shuaib Zarinkhail 2010